AWS テクニカルサポートで得た暗黙知をまとめてみた

AWS テクニカルサポートを 5 年経験して

アノテーションの荒川です。

クラスメソッドメンバーズをご契約いただいているお客様のテクニカルサポート業務を始めて、早 5 年が経過しました。

私が対応したチケット件数をざっくりと調べたところ、本日時点で 1685 件でした。

最近は私がチケット対応する機会は減りまして、チケット対応メンバーの教育（新入社員から各チームへ所属するまでの育成）やチケット相談に使う時間がメインです。

その中で、今まで何となくこうやって対応すると上手くいくと感じていた暗黙知をメモ書きしていたので、今回ブログとして公開します。

回答者側で意識したいこと

技術的なお問い合わせに関するガイドラインを参考にする

AWS サポートのガイドラインは、一般的なカスタマーサポートでも使えます。

一文を短くし、適宜改行を挿入する

例: 一行にぎっしり

• × お客様環境をお調べしたところ、EC2 インスタンスに問題があり、この問題によって CloudWatch メトリクスが出力されなくなり、結果としてアラームが不十分なデータを検知しました。

• ○ お客様環境をお調べしたところ、EC2 インスタンスに問題が発生していました。
  この問題によって CloudWatch メトリクスが出力されなくなりました。
  CloudWatch メトリクスが欠落したため、アラームは不十分なデータを検知しました。

情報の正確度を伝える

例: 解決への道順を作る

• 事実
  • 当方で AWS ドキュメント通りに検証したところ、お問い合わせの事象は再現されず正常に実行できました。
• 予想
  • 原因切り分けの結果から、オンプレミス側でネットワーク関連の問題が発生している状況と見受けられます。
• 伝聞
  • 以下に AWS サポートの回答を記載します。
    <回答を転載する>

  ※ 引用した内容で 2 者間（確認先・エンドカスタマー）のズレがないかを要チェック。ズレがある場合は情報の整理をし、必要に応じて両者へ状況の共有を行う。

• 確認
  • 実施されたコマンドの全文、および出力されたエラーメッセージの全文をご提供ください。

質問の言葉を回答に使う

例: 技術的に可能ですか？

• × できなくもないですが、必要な手順が多くなります。
• ○ 技術的に可能です。ただし必要な手順は多くなります。

ニュアンスを含む言葉は使わない

例: 無理なものは無理、頑張ってやっても労力に見合わないものだったりする。

• × 難しいです。
  • 「頑張ればできるの？」と思われることも
• ○ AWS ドキュメントをお調べしましたが、実施する方法はございませんでした。

質問を引用する

長い質問の場合はすべてを引用するのではなく、質問箇所のみ引用しましょう。

丁寧にすることを目的とした「存じます」は使わない

で、結局はどっちなの？という疑問を生みます。

例: ドキュメントの情報を「存じます。」

• × ドキュメント通りであれば xx かと存じます。
• ○ ドキュメント通りであれば xx になります。

質問者が迷わない連絡をする

例: 見出し + 順序立て

• × もし xx の検証結果が A でなければ B を実施し、B の後に C を実施してください。

A も B も実施せずに「C を実施しました。ダメでした。」という連絡を受けたことがあります。

• ○ 以下の通り検証を行ってください。
  検証方法

  ■ 検証の結果が A の場合
  この時点で出力されたエラーメッセージ全文をご連絡ください。

  ■ 検証の結果が A 以外の場合
  以下の手順に沿って、追加の検証にご協力をお願いします。

  1. B を実施してください。
  2. C を実施してください。
  3. 出力されたメッセージやスクリーンキャプチャをご提供ください。

追加の質問を予想する

例: ドキュメント丸投げ

• × ドキュメントに沿ってご対応ください。
• ○ ドキュメントのステップ 1 〜 ステップ 5 を実施した後、「準備完了」というステータスになれば完了です。

質問者が本当に困っていること（カスタマーペイン）を解決する

常に質問者が解決したい問題はどこにあるかを推測し、その問題を解決することに注力しましょう。

質問者側で意識したいこと

一般的でない言葉の使用を控える

例: 関係者以外の相手へ伝わりづらい言葉

• × AN の DEV 環で、〜お願いしたく。
• ○ アノテーション株式会社の開発環境で、〜をお願いします。

社内共通語は相手に伝わるように変換する

例: 相手も知ってる前提にしないで

• × CMP、DevIO
• ○ クラスメソッドメンバーズポータル、弊社ブログ

次に取るアクションを明確にする

例: つぶやき？

• × 非常に困っています。このような事象が起こることに驚いてます。過去事例はあるのでしょうか？

多くのケースでは過去事例の有無の回答を期待していません。過去事例の有無を返事したところで追加質問が来るだけです。

• ○ 本番環境で運用しているので、再発を予防したいです。事象の影響を抑える方法や構成があれば教えてください。
  また、AWS マネージドサービス側の問題であれば、AWS サポートへ改善要望としてフィードバックをお願いします。

例: 何をお願いしたいか不明瞭

• × 〜という事象が発生します。確認をお願い致します。

言われた通りに「確認しました。」という回答ではほとんどのパターンが満足されません。（理不尽）

• ○ 〜という事象が発生します。この事象が発生しないようにしたいので、対策を教えてください。

なるべく Yes/No で返しやすい質問をする

• 解決までの速度を早めるため
• 気になったことは、「どうして？なぜ？」と質問する前に検証したり周りへ相談する
  • 検証しても周りへ相談してもわからなければ、結果と問題の再現手順を回答者へ伝える

質問者・回答者側共通で意識したいこと

必要以上にお詫びをしない、感謝をする

※ もちろん、本当に迷惑をかけてしまったときは、正直にお詫びをしましょう。

例: 確認で相手を待たせたときの連絡

• × 確認に時間をかけてしまい大変申し訳ございません。

このメッセージを受け取った相手が「私は対応を後回しにされたのか」などとネガティブに捉えやすくなる印象があります。

• ○ 確認にお時間をいただきありがとうございます。

丁寧にすることを目的とした否定形の質問をしない

例: 〜できませんでしょうか？

• × S3 に保存されたスナップショットのデータをユーザー側で見ることができませんでしょうか？
• ○ S3 に保存されたスナップショットのデータをユーザー側で見れますか？

まとめ

今回私が個人的にいつも意識しているような暗黙知をまとめてみました。まとめておいておかしな話ですが、私も上記のことをできないことがあるのでメモしています。

テクニカルサポート業務にかかわらず、普段から文章で質疑応答をする機会が多い方の参考になれば幸いです。

今後も暗黙知が溜まったら新たなブログにしていきたいと考えています。次回作にご期待ください。（終）

参考

• 技術的なお問い合わせに関するガイドライン | AWS サポート

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、さまざまな背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。